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© Data decompression and transfer system. 

© A system and method for transfer of com- 
pressed data that dynamically chooses between 
hardware and software compression/decompression 
(CODEC) so as to maximize the usage of any digital 
signal device hardware capabilities; and that pro- 
vides a common, uncompressed data interchange 
format for applications regardless of any compres- 
sion technique that may have been used to create 
the data file. 



200b I 



DIGITAL 
SIGNAL 
DEVICE 



DIGITAL 
SIGNAL 
PROCESSOR 



DIGITAL SIGNAL 
APPLICATION 



,206C 
206b 




UNCOMPRESSED 
DIGITAL SIGNAL 
FILE 



COMPRESSED 
DIGITAL SIGNAL 
FILE 



FIG. 2 



Rank Xerox (UK) Business Services 



1 



EP 0 685 824 A2 



2 



FIELD OF THE INVENTION 

This invention relates generally to decompres- 
sion and transfer of data, specifically in systems 
that store and process digitized audio, video, and 
other signals using one or more compression tech- 
niques. 

BACKGROUND OF THE INVENTION 

Digital signal devices ("devices") are computer 
peripheral devices that interface between comput- 
ers and components that process analog signals, 
for example microphones, speakers, video cam- 
eras, or tape recorders. These devices may pro- 
cess a variety of data types including video, 
graphical, and audio signals. For example, "audio 
devices" are devices that process audio data. A 
commonly known type of audio device is a "sound 
board" connectable to a bus in a computer system. 
There are a number of commercially available 
sound boards. 

A digital signal device periodically samples an 
analog input signal and encodes the sampled sig- 
nal amplitude to generate a stream of digital words, 
which form "digital signals" or "digitized data". The 
name associated with the data may reflect its con- 
tent, for example "audio data". The data can be 
stored in computer files, for example as a digital 
representation of music or animation. Digital signals 
can also be incorporated into files that contain 
other kinds of data, for example audio data may be 
incorporated into electronic mail, word processing, 
or spreadsheet files. 

Digital signal applications ("applications") are 
programs that allow a user to manipulate stored 
digital signals, for example, to compose music or 
to cut a segment of audio data from one file and 
■pasio il into another lilo. A number of such digital 
signal applications aro commorcially available. Ap- 
plications and digital signal dovicos interact with 
files of stored digital data by means of a file 
input/output (I/O) handler. The file I/O handler can 
be part of the computer operating system, and 
manages the administrative operations of opening 
and closing files and actually storing and retrieving 
data in a storage device. 

An application can interact with a digital signal 
device by instructing the device to convert an 
analog input signal into a digital signal and to store 
the digital signal in a file ("recording"), or by in- 
structing the device to retrieve a digital signal from 
a file and to convert the digital signal into an 
analog output signal ("playback"). Recording and 
playback are commonly referred to as "real-time" 
operations because the conversions required 
should take no longer than the actual time duration 
of the analog signal. During recording, playback, 



and other real-time operations, the application does 
not process the digital data, instead the digital 
signal device interacts directly with the file. 

The increased use of digital audio, video, and 
s other signal processing applications and devices 
has increased the amount of digital signal data that 
must be stored and processed by computers. Al- 
though the sampling rate and the number of bits 
per sample determine the actual amount of space 

io required to store a given digital signal, in general, 
the space required is relatively large. Digital signals 
may include each bit of each sample, commonly 
referred to as "pulse code modulated (PCM)" or 
"uncompressed" signals. Alternately, the signals 

75 may be compressed to reduce the required storage 
space, commonly referred to as "compressed" sig- 
nals. 

Various techniques are used to perform the 
compression. These compression techniques are 
20 not compatible with one another, in that a file 
produced using one compression technique cannot 
be expanded or decompressed using another tech- 
nique. Some of the more common techniques in- 
clude Adaptive Pulse Code Modulation (APCM), u- 
25 law, and Run-Length Encoding (RLE). Generally, a 
file does not contain a mixture of compressed and 
uncompressed data, nor data produced by a mix- 
ture of compression techniques. 

Some digital signal devices incorporate a hard- 
30 ware component known as a digital signal proces- 
sor (DSP) and its associated memory and control 
circuitry. Hereinafter, a DSP and its associated 
components are referred to collectively as a 
"DSP". These devices can use the DSP to com- 
as press and decompress (COompress/DECompress 
or "CODEC") digital signals; this is commonly re- 
ferred to as a "hardware CODEC" technique. DSP- 
equipped devices can also process uncompressed 
digital signals, but this wastes resources, since 
40 DSP-oquippod dovicos aro moro oxponsivo than 
devices without DSPs. 

Devices without a DSP cannot process most 
compressed digital signals, and thus generally only 
operate with uncompressed digital signals. If such 
45 a device must operate with a compressed file, the 
CODEC function must be performed by software 
running on a central processing unit (CPU) in the 
associated computer before the device stores or 
retrieves the data from the file; this intermediate 
so CODEC function is commonly referred to as a 
"software CODEC" technique. 

Mismatches sometimes occur between a file's 
data type, uncompressed or compressed, and a 
device's ability to perform a hardware CODEC 
55 function. When these mismatches occur, they lead 
to one of two major problems: degraded system 
performance or poor resource utilization. Specif^ 
cally, a compressed file being processed by a 
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device that lacks hardware CODEC capabilities re- 
quires the CPU to perform extra processing, i.e. 
software compression/decompression, and so neg- 
atively impacts overall system performance. On the 
other hand, an uncompressed file being processed 
by a device that possesses hardware CODEC ca- 
pabilities underutilizes the relatively expensive DSP 
and wastes storage space and I/O bandwidth, since 
a compressed file would take much less space. 

Until now, creators of commercial digital signal 
files generally were compelled to supply uncom- 
pressed files in order to ensure maximum compati- 
bility with the range of available devices. This con- 
sumed large amounts of file storage space; it also 
underutilized the DSP on systems with devices 
capable of performing a hardware CODEC function. 

In a manner similar to digital signal devices, 
applications that manipulate digital signals must be 
able store and retrieve digital signals from files 
where the data may have been compressed using 
one of many compression techniques. In prior art 
systems, in order to store or retrieve data from a 
compressed file, an application must contain a soft- 
ware CODEC routine that matches the file's com- 
pression type. 

Further, data is commonly structured when it is 
stored in a file. Specifically, the structure accords 
with a "file format", i.e. a specification of the layout 
of data words in the file's data portion and the 
content and layout of a file header. File formats are 
independent of the file contents, moreover applica- 
tions may create several files, all containing the 
same type of data, but using different file formats. 
Files are often formatted differently under different 
operating systems, for example MS-DOS and OS/2 
®. Thus, each software CODEC routine must be 
written to compress and decompress data using 
both a particular compression technique and a par- 
ticular file format. Since there are numerous com- 
pression types and file formats, each application 
must contain many such software CODEC routines 
in order to be compatible with as many compres- 
sion types and file formats as possible. 

However, applications that contain many 
CODEC routines have program size and complexity 
problems. Large or complex programs are more 
difficult to write, debug, and maintain. Each ap- 
plication writer must duplicate CODEC routines that 
already exist in other applications, introducing the 
problem of duplicated effort. New compression 
techniques are constantly being developed, so up- 
dating existing applications is also problematic. On 
the other hand, an application with only one or a 
small number of CODEC routines has a disadvan- 
tage in that it can process only a limited number of 
compression types and file formats. 

Some prior art systems, therefore, support mul- 
tiple compression types. These systems fall into 



two groups: "hardware-only" CODEC systems and 
"software-only" CODEC systems. Hardware-only 
CODEC systems ensure that devices will be able 
to process any file by always requiring a DSP. 

5 These systems have two disadvantages. They pre- 
clude the use of less expensive devices, ones 
without a DSP, and since they do not compress or 
decompress data transferred between applications 
and files, they fail to solve the application size and 

io complexity problem. 

There are also software-only CODEC systems, 
which perform all CODEC functions in software, 
regardless of whether a DSP is available. The file 
I/O handler in these systems typically detects a 

75 file's format and which, if any, compression tech- 
nique was used by reading the file header upon 
opening the file. The file I/O handler maintains a 
library of CODEC routines. Using the appropriate 
routine, the file I/O handler passes uncompressed 

20 data to and from the application or device, regard- 
less of the file's compression type. However, when 
a DSP-equipped device is available, these systems 
waste valuable CPU time performing software 
CODEC functions, and therefore negatively impact 

25 overall system performance. 

Consequently, neither hardware-only nor soft- 
ware-only CODEC systems solves the problems of 
resource utilization and application size and com- 
plexity. 

30 

SUMMARY OF THE INVENTION 

Accordingly, the present invention provides a 
method for transferring data including compressed 

35 data to utilization means in response to a request, 
the method comprising the steps of: determining 
whether the utilization means contains hardware for 
decompressing the compressed data; ascertaining 
a compression technique used to compress the 

40 compressed data; transferring the compressed data 
to the utilization means; using a software routine to 
decompress the compressed data when the utiliza- 
tion means does not contain the hardware; and 
controlling the hardware to decompress the com- 

45 pressed data in accordance with the compression 
technique when the utilization means does contain 
the hardware. 

According to another aspect, the invention also 
provides a data transfer system for transferring 

so data including compressed data to utilization 
means in response to a request, the system com- 
prising: means responsive to the request for deter- 
mining whether the utilization means contains hard- 
ware for decompressing the compressed data; 

55 means responsive to the request for ascertaining a 
compression technique used to compress the com- 
pressed data; a file I/O handler responsive to the 
request for transferring the data to the utilization 
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means, the file I/O handler being controllable to 
decompress the compressed data while transfer- 
ring the data to the utilization means; means coop- 
erating with the determining means and the ascer- 
taining means for controlling the file I/O handler to 5 
decompress the data when the utilization means 
does not contain the hardware; and means for 
controlling the hardware to decompress the com- 
pressed data in accordance with the compression 
technique when the utilization means does contain w 
the hardware. 

Systems according to the invention can trans- 
late between a common, uncompressed data for- 
mat and any of several compressed data formats. 
These systems dynamically choose to perform the ;s 
translation in software or in hardware. These sys- 
tems base the choice on the particular data com- 
pression format used, and on the presence or 
absence of hardware translation resources. 

This is achieved by dynamically choosing be- 20 
tween hardware and software CODEC techniques 
based on the hardware resources available and on 
each file's compression type. The invention further 
provides a common, uncompressed data inter- 
change format between applications and data files, 25 
regardless of the compression technique or file 
format used to create the data file. 

More specifically, a preferred embodiment of 
the invention employs a digital signal manager 
positioned between the file I/O handler and digital 30 
signal devices or application programs. In response 
to a file's compression type, as indicated in the 
file's header, and the characteristics of the digital 
signal device, as stored in a "resource file" or as 
sensed by the digital signal manager or by inter- 35 
rogating tho device directly, the digital signal man- 
ager dynamically selects either a hardware or soft- 
ware CODEC technique for transfers between the 
digital signal device and the file. The digital signal 
manager also provides a common data interchange 40 
format to the application programs, which in accor- 
dance with an illustrative embodiment, is uncom- 
pressed data. Thus, each application need only be 
concerned with a single compression type and file 
format. 45 

More particularly, in response to an applica- 
tion's request to open a file, if an existing file 
contains compressed data, or a new file is to 
contain compressed data, the digital signal man- 
ager instructs the file I/O handler to invoke the 50 
appropriate decompression routine when the ap- 
plication retrieves data from the file, and to invoke 
the appropriate compression routine when the ap- 
plication stores data in the file. If the file contains 
uncompressed data, or a new file is to contain 55 
compressed data, the digital signal manager in- 
structs the file I/O handler to pass the data unmodi- 
fied between the application and the file. That is, 



the digital signal manager makes all files appear to 
the application as though they were uncompressed. 
This common, uncompressed, data format provides 
compatibility between substantially all applications 
and substantially all digital signal files, regardless 
of which, if any, compression techniques were 
used to create the files. 

The digital signal manager maintains resource 
files that contain selected operating characteristics 
of each available digital signal device. The re- 
source files may be supplied, for example, by the 
device vendors. These characteristics include in- 
formation concerning the device's operating mode- 
(s). including, for each operating mode, the sam- 
pling rate, i.e. the number of samples per second 
taken by the device; the precision, i.e. the number 
of data bits per sample; and the number of analog 
channels used. The resource files also include ad- 
ditional information, such as the presence and 
quantity in the device of various hardware compo- 
nents useful for data compression or decompres- 
sion, for example a DSP and the amount of mem- 
ory available to the DSP. 

In response to an application's request to es- 
tablish a file handle between an existing file and a 
digital signal device, the digital signal manager 
uses the file I/O handler to read the file's header 
and to ascertain the file's characteristics. These 
characteristics include the sampling rate, precision, 
number of channels, and which compression tech- 
nique, if any. was used to create the file. If the 
application specifies a new file, then the application 
may specify the file's characteristics, although the 
file I/O handler specifies default characteristics. 
The digital signal manager uses both the file's 
characteristics and the device's hardware charac- 
teristics, as reflected in the resource file, to decide 
whether the device can process the data directly, 
or whether the data must be compressed or de- 
compressed by a software CODEC routine first. 

Tho digital signal manager thon controls tho filo 
I/O handler to transfer the data in an appropriate 
manner. For example, if the digital signal manager 
ascertains that the device can directly process the 
data in the file, the digital signal manager adjusts 
the device's operating characteristics to match as 
closely as possible the characteristics under which 
the data file was created. The digital signal man- 
ager then instructs the file I/O handler to pass the 
data directly between the device and the file, that 
is, without the file I/O handler compressing or de- 
compressing the data. 

Alternatively, if the digital signal manager as- 
certains that the data must be compressed or de- 
compressed before the transfer, the digital signal 
manager instructs the file I/O handler to invoke the 
appropriate decompression routine when the de- 
vice reads from the file, and the appropriate com- 
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pression routine when the device writes to the file; 
the file I/O handler performs software compres- 
sion/decompression. 

The use of the digital signal manager to decide 
whether the data must be compressed or decom- 
pressed by a software CODEC routine enhances 
resource utilization. A DSP is utilized whenever 
possible to process the data, freeing the central 
processing unit (CPU) to perform other functions. 
The CPU performs software compres- 
sion/decompression only when the device is in- 
capable of processing the data directly, yet devices 
without DSPs are not limited to operating with 
uncompressed data files. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and further advantages of the inven- 
tion may be better understood by referring to the 
following description in conjunction with the accom- 
panying drawings, in which: 

Fig. 1 is a schematic block diagram of a com- 
puter on which an embodiment of the invention 
can be practised; 

Fig. 2 is a schematic block diagram showing a 
data transfer system according to the invention 
in relation to other software and hardware com- 
ponents with which it interacts; 
Fig. 3 is a flow chart, which illustrates aspects of 
a method according to the invention related to 
the system illustrated in Fig. 2; 
Fig. 4 is a flow chart, which illustrates a method 
according to the invention in relation to the 
system illustrated in Fig. 2; and 
Figs. 5A , 5B and 5C combine to form a flow 
chart, which illustrates in more detail a portion of 
the method illustrated in Fig. 4. 

DETAILED DESCRIPTION OF ILLUSTRATIVE EM- 
BODIMENTS 

The invention is preferably practised in the 
context of an operating system resident on a per- 
sonal computer, such as the system represented in 
Fig. 1. The computer 100 is controlled by a central 
processing unit (CPU) 102, which may be a con- 
ventional microprocessor, and a number of other 
units, which are provided to accomplish specific 
tasks. A system bus 104 interconnects the CPU 
102 and the other units. Although a particular com- 
puter may only have some of the units illustrated in 
Fig. 1, or may have additional components not 
shown, most computers will include at least the 
units shown. Specifically, the computer 100 in- 
cludes a read-only memory (ROM) 106 for perma- 
nent storage of the computer's configuration and 
basic operating commands; a random access 
memory (RAM) 108 for temporary storage of 



instructions and data; an input/output (I/O) adapter 
110 for connecting peripheral devices such as a 
disk unit 112; a keyboard adapter 114 for connect- 
ing a keyboard 116; a display adapter 118 for 
5 connecting a display 120; and a digital signal de- 
vice, which in this example is a sound board 122 
for connecting a speaker 124 and a microphone 
126. Hereinafter, the ROM 106, RAM 108, and disk 
unit 112 collectively are referred to as the "data 
10 storage units". 

Fig. 2 depicts various files containing programs 
and data and resident in the various data storage 
units in the system. The system may contain one 
or more digital signal devices, for example 200a, 
75 200b, and 200c. Optionally, one or more devices, 
such as 200c, may incorporate a digital signal 
processor (DSP) 202. In the preferred embodiment 
of the invention, the vendor who supplies a device 
also supplies a resource file, for example 204a, 
20 204b, or 204c, corresponding to the device 200a, 
200b, or 200c, respectively. Hereinafter, the re- 
source file is referred to as "resource file 204". 
Each resource file 204 lists, for example, whether 
the associated device 200 incorporates a DSP, the 
25 amount of memory associated with the DSP, the 
characteristics of the device 200 that can be ad- 
justed and the range of values of these characteris- 
tics. The use of the resource file 204 is described 
in more detail below. 
30 The system contains one or more applications, 

for example 206a, 206b, and 206c, each resident in 
the RAM 108 or ROM 106 of Fig. 1. Hereinafter, 
the application is referred to as "application 206". 
Digital signal files 208, 210a, 210b, and 210c 
35 contain digital signals. File 208 contains uncom- 
pressed data. Files 21 0a, 210b, and 210c, on the 
other hand, contain data compressed according to 
different compression techniques, although more 
than three such techniques exist. Each file contains 
40 a data portion containing digital signals and a head- 
er portion specifying characteristics of the data 
portion, e.g. sampling rate, bits per sample and 
compression format, i.e. uncompressed or com- 
pression technique. The application 206 or the de- 
45 vice 200 interacts with a file 208 or 210 by means 
of a file input/output (I/O) handler 212. The file I/O 
handler 212 is part of the computer operating sys- 
tem 214, and it manages the administrative oper- 
ations of opening and closing the files and actually 
so storing and retrieving data in a storage device. The 
operating system 214 and its file I/O handler 212 
reside in the RAM 108 and/or ROM 106 of Fig. 1. 

An application 206 can perform two types of 
operations. In the first type, the application 206 
55 reads and/or writes a digital signal in one or more 
files 208 and/or 210 in order to perform a non-real- 
time operation, for example to cut a segment of 
audio data from one file and paste it into another 



5 



9 



EP 0 685 824 A2 



10 



file. In the second type of operation, the application 
206 instructs the device 200 to perform a real-time 
operation, for example record or play back, and the 
device 200 then reads or writes a digital signal in a 
file 208 or 210. These two types of operation are 5 
described in detail below. 

When performing an operation of the first type, 
non-real-time, the application 206 sends a request 
to the operating system 214, i.e. to a digital signal 
manager 216. The request identifies the file 208 or 10 
210 to be processed. The digital signal manager 
216 performs the operations generally illustrated in 
the flow chart in Fig. 3. Thus the digital signal 
manager 216 begins at step 300 and sends a 
request at step 302 to the file I/O handler 212 to 75 
open the file 208 or 210 and to detect which, if 
any, compression technique was used to create the 
file, and in which format the file exists. 

The file I/O handler 212 may contain an "I/O 
procedure", for example 218a, 218b, or 218c, for 20 
each combination of file format and storage me- 
dium that the system supports. Each I/O procedure 
is capable of storing data in and retrieving data 
from a file, and translating between the file's format 
and a common format. The file I/O handler 212 25 
interrogates the I/O procedures until it finds one 
that recognizes the file 208 or 210; the file I/O 
handler uses this I/O procedure for all transfers to 
and from the file 208 or 210. This arrangement, 
which is not part of the present invention, is de- 30 
scribed in more detail in commonly assigned Unit- 
ed States patent application serial number 
07/960,976, filed on December 31, 1991 by D. M. 
Dorrance, et al, for a Data Processing File Format 
Transparency System, which is hereby incorpo- 35 
rated by reference. The file I/O handler 212 also 
detects which, if any. compression technique was 
used to create the file 208 or 210 by reading the 
file's header, and provides this information to the 
digital signal manager 216. 4Q 

At step 304 the digital signal manager 216 
examines the response from the file I/O handler 
212. If the file is uncompressed, the digital signal 
manager 216 establishes at step 306 a file handle 
220 between the file I/O handler 212 and the ap- 45 
plication 206. A file handle is sometimes referred to 
as a "channel", and il is well known how to estab- 
lish a filo handlo. Soo, for example, Multimedia 
Pro suntalion Manager Programm e r Huleronce , IBM 
order number 7\<a2Z22. The application 206 then 50 
reads and/or writes in the file 208. The digital 
signal manager 216 finishes at step 308. 

If the file is compressed, the file I/O handler 
212 loads into the file I/O handler the appropriate 
compression type-specific compres- 55 

sion/decompression (COmpression/DECompression 
or CODEC) routine, for example 222a, 222b, or 
222c. This process, which is not part of the present 



invention, is described in more detail in commonly 
assigned United States patent application serial 
number 07/981040, filed on November 24, 1992 by 
Fetchi Chen and Daniel Michael Dorrance, for a 
Software Mechanism for Providing CODEC Trans- 
parency, which is hereby incorporated by refer- 
ence. The digital signal manager 216 establishes at 
step 310 a file handle 220 between the file I/O 
handler 212 and the application 206. The digital 
signal manager 216 instructs the file I/O handler 
212 to use the appropriate CODEC routine 222 for 
the data transfers between the application 206 and 
the file 210. The CODEC routine 222 decom- 
presses the data as the application 206 reads from 
the file 210 and compresses the data as the ap- 
plication 206 writes to the file 210. The digital 
signal manager 216 finishes at step 308. 

Thus, the. digital signal manager 216 ensures 
that the application 206 exchanges data with the 
file 208 or 210 in a common, uncompressed for- 
mat. 

In the second type of operation, the application 
206 instructs a device 200 to perform a real-time 
operation. The flow chart in Fig. 4 illustrates gen- 
erally the operation of the digital signal manager 
216 when it performs an operation of the this type 
The application 206 sends a request to the operat- 
ing system 214, i.e. to the digital signal manager 
216. The request indicates that the application 206 
directs a device 200 to read or write a digital signal 
in a file 208 or 210. 

The digital signal manager 216 starts at step 
400. At step 402, it ascertains which characteristics 
of the device 200 can be adjusted and the range of 
values these characteristics can take on. In the 
preferred embodiment, the digital signal manager 
216 ascertains the device's characteristics, step 
402, by reading the resource file 204. In an al- 
ternate embodiment, the digital signal manager 216 
ascertains the device's characteristics by interro- 
gating the device 118. These characteristics in- 
clude the number of samples per second; the pre- 
cision, i.e. number of data bits per sample; and the 
number of channels used. Also at step 402, the 
digital signal manager 216 determines whether the 
device 200 has a DSP 202, and if so, the amount 
of memory available to tho DSP. 

At stop <104 , tho digital signal mannnor 210 
sends a request to the file I/O handler 2t2 to open 
the file 208 or 210 and to detect which, if any, 
compression technique was used to create the file. 
At step 406 the digital signal manager 216 exam- 
ines the response from the file I/O handler 212. If 
the file is uncompressed, at step 408 the digital 
signal manager 216 sets the device's adjustable 
characteristics, thereby instructing the device 200 
to process an uncompressed digital signal. The 
digital signal manager 216 sets the device's adjust- 
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able characteristics by well known means, for ex- 
ample by setting and clearing the appropriate bits 
in the device's control registers. The digital signal 
manager 216 establishes at step 410 a file handle 
224 between the file I/O handler 212 and the de- 
vice 200. The device 200 then reads from and/or 
writes to the file 208. The digital signal manager 
216 finishes the operation at step 412. 

If the file is compressed, at step 414 the digital 
signal manager 216 determines whether the device 
200 has a DSP 202 and sufficient memory to 
process the digital signal. If the device 200 does 
not have a DSP or does not have sufficient mem- 
ory, the digital signal manager 216 establishes at 
step 416 a file handle 224 between the file I/O 
handler 212 and the device 200. The digital signal 
manager 216 instructs the file I/O handler 212 to 
use a CODEC routine 222 for the data transfers 
between the device 200 and the file 210. The 
CODEC routine 222 decompresses the data as the 
device 200 reads from the file 210 and compresses 
the data as the device 200 writes to the file 210. 
Although the hie 210 is actually compressed, the 
device 200 will then process uncompressed data. 
Therefore, at step 418 the digital signal manager 
216 sets the device's adjustable characteristics, 
thereby instructing the device 200 to process an 
uncompressed digital signal. The digital signal 
manager 216 finishes at step 412. 

If the device 200 has a DSP and sufficient 
memory to process the digital signal, the digital 
signal manager 216 at step 420 calculates the 
appropriate values for the device's adjustable char- 
acteristics. Tho digital signal manager 2IG matches 
these values as closely as possible to the char- 
acteristics under which the digital signal file was 
created. The digital signal manager 216 calculates 
the number of bits per sample, the number of 
channels, and the sampling rate (the number of 
samples per second) to be used by the device 200. 

The flow charts of Fig. 5A, 5B, and 5C illustrate 
generally the operations of step 420. Referring first 
to Fig. 5A, the digital signal manager 216 starts the 
number-of-bits-per-sample calculation at step 500, 
and at step 502 it sets the "current approximation" 
to the number of bits per sample in the device's 
first mode of operation. At step 504 it tests whether 
the device 200 has any more modes of operation 
to consider. If there are no more modes to con- 
sider, at step 506 the digital signal manager sets 
the "number of bits per sample closest match" to 
the "current approximation" and at step 508 it 
transfers to the flowchart in Fig. 5B. 

If there are more modes of operation to con- 
sider, the digital signal manager 216 at step 510 
sots "X" to tho number of bits por sample in the 
dovico's noxl rnodo ol oporalion. Al slop l>\2 tho 
digital signal manager 216 sets "A" to the absolute 



value of the difference between the file's 210 num- 
ber of bits per sample and the "current approxima- 
tion". At step 514 the digital signal manager 216 
sets "B" to the absolute value of the difference 

5 between the file's 210 number of bits per sample 
and "X". At step 516 the digital signal manager 
216 compares "A" with "B". If "B" is greater than 
"A" the digital signal manager 216 loops directly 
back to step 504. Otherwise, at step 518 it sets the 

70 "current approximation" to "X" and loops back to 
step 504. 

In Fig. 5B, the digital signal manager 216 starts 
the number-of-channels calculation at step 600, 
and at step 602 it sets the "current approximation" 

15 to the number of channels in the device's first 
mode of operation. At step 604 it tests whether the 
device 200 has any more modes of operation to 
consider. If there are no more modes to consider, 
at step 606 the digital signal manager sets the 

20 "number of channels closest match" to the "cur- 
rent approximation" and at step 608 it transfers to 
the flowchart in Fig. 5C. 

If there are more modes of operation to con- 
sider, the digital signal manager 216 at step 610 

25 sets "X" to the number of channels in the device's 
next mode of operation. At step 612 the digital 
signal manager 216 sets "A" to the absolute value 
of the difference between the file's 210 number of 
channels and the "current approximation". At step 

so 614 the digital signal manager 216 sets "B n to the 
absolute value of the difference between the file's 
210 number of channels and "X". At step 616 the 
digital signal manager 216 compares "A" with "B". 
If "6" is groator than "A" the digital signal man- 

35 ager 216 loops directly back to step 604. Other- 
wise, at step 618 it sets the "current approxima- 
tion" to "X" and loops back to step 604. 

In Fig. 5C, the digital signal manager 216 starts 
the sampling rate calculation at step 700, and at 

40 step 702 it sets the "current approximation" to the 
sampling rate in the device's first mode of opera- 
tion. At step 704 it tests whether the device 200 
has any more modes of operation to consider. If 
there are no more modes to consider, at step 706 

45 the digital signal manager sets the "sampling rate 
closest match" to the "current approximation" and 
at step 708 it finishes. 

If there are more modes of operation to con- 
sider, the digital signal manager 216 at step 710 

50 sets "X" to the sampling rate in the device's next 
mode of operation. At step 712 the digital signal 
manager 216 sets "A" to the absolute value of the 
difference between the file's 210 sampling rate and 
the "current approximation". At step 714 the digital 

55 signal manager 216 sets "B" to the absolute value 
of tho difforence botwoon tho file's 210 sampling 
ralo and "X". At slop 710 Iho digital signal man- 
ager 216 compares "A" with "B". If "B" is greater 
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than "A" the digital signal manager 216 loops back 
to step 704. Otherwise, at step 718 it sets the 
"current approximation" to "X" and loops directly 
back to step 704. 

At step 422 in Fig. 4 the digital signal manager 5 
216 sets the device's adjustable characteristics so 
they are consistent with those calculated at step 
420. The digital signal manager 216 establishes at 
step 410 a file handle 224 between the file I/O 
handler 212 and the device 200. The device 200 10 
then reads and writes to the file 208. The device 
200 performs the CODEC function; this is called 
"hardware CODEC". The digital signal manager 
216 finishes at step 412. 

Thus, the digital signal manager 216 dynam- 75 
ically chooses between hardware and software 
CODEC techniques and in so doing it maximizes 
the usage of the digital signal devices' hardware 
capabilities. That is, it uses hardware CODEC tech- 
niques whenever they can be used in processing 20 
the digitized signals and it uses software CODEC 
routines whenever hardware CODEC techniques 
cannot be used. It thus provides for the operation 
of non-compression-specific application programs 
while optimizing the overall efficiency of the sys- 25 
tern in dealing with digital signal files. 

Claims 

1- A method for transferring data including com- 30 
pressed data (210) to utilization means (200) in 
response to a request, the method comprising 
the steps of: 

determining (402) whether the utilization 
means (200) contains hardware (202) for de- 35 
compressing the compressed data; 

ascertaining (404, 406) a compression 
technique used to compress the compressed 
data; 

transferring (410, 416) the compressed 40 
data to the utilization means; 

using a software routine (222) to decom- 
press the compressed data when the utilization 
means does not contain the hardware; and 

controlling (422) the hardware (202) to de- 45 
compress the compressed data in accordance 
with the compression technique when the utili- 
zation means does contain the hardware. 

2. A method as claimed in claim 1 in which said 50 
tJolormining stop comprisos the further steps 
of: 

obtaining a resource file (204) containing 
characteristics of the utilization means; and 

reading the resource file to determine 55 
whether the utilization means contains the 
hardware. 



3. A method as claimed in either claim 1 or claim 
2 in which said ascertaining step comprises 
reading information relating to the compression 
technique from header information in a file of 
compressed data to be transferred. 

4. A method as claimed in any preceding claim 
including the steps of determining (304, 406) 
whether data to be transferred is compressed 
or uncompressed and transferring uncompres- 
sed data directly to said utilization means. 

5. A method as claimed in claim 4 for use in a 
system in which said utilization means includes 
a digital signal device (200) and which system 
includes an application program (206) for is- 
suing requests for data transfer either to said 
digital signal device or to the application pro- 
gram itself, the method including the further 
step, where data to be transferred to the ap- 
plication program is compressed, of using 
(310) a software routine (222) to decompress 
that data. 

6. A method as claimed in any preceding claim 
which includes the further step, in response to 
a determination that the utilization means con- 
tains said decompression hardware and that 
the data to be transferred is compressed, of 
setting the characteristics of the utilization 
means and decompression hardware to match 
characteristics of the compressed data. 

7. A method as claimed in claim 1 in which said 
determining step comprises directly interrogat- 
ing the utilization means in order to determine 
whether the utilization means contains the 
hardware. 

8. A data transfer system for transferring data 
including compressed data (210) to utilization 
means (200) in response to a request, the 
system comprising: 

means (402) responsive to the request for 
determining whether the utilization means con- 
tains hardware (202) for decompressing the 
compressed data; 

means (404, 406) responsive to the re- 
quest for ascertaining a compression techniquo 
used to compross the comprossod data; 

a filo I/O handler (212) rosponsivo to the 
request for transferring the data to the utiliza- 
tion means, the file I/O handler being control- 
lable to decompress the compressed data 
while transferring the data to the utilization 
means; 

means (416) cooperating with the deter- 
mining means and the ascertaining means for 
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controlling the file I/O handler to decompress 
the data when the utilization means does not 
contain the hardware; and 

means (422) for controlling the hardware to 
decompress the compressed data in accor- 5 
dance with the compression technique when 
the utilization means does contain the hard- 
ware. 

9. A system as claimed in claim 8 further com- 70 
prising a resource file (204) containing char- 
acteristics of the utilization means and wherein 

the determining means is arranged to read the 
resource file to determine whether the utiliza- 
tion means contains the hardware. 75 

10. A system as claimed in either claim 8 or claim 

9 in which the ascertaining means is arranged 
to road information relating to the compression 
technique from header informalion in a file of 20 
compressed data to bo transferred. 

11. A system as claimed in any one of claims 8 to 

10 wherein the utilization means comprises a 
digital signal device, the digital signal device 25 
including said decompression hardware. 

12. A system as claimed in any one of claims 8 to 

11 including means responsive to said deter- 
mining means (402) determining that the utili- 30 
zation means contains said decompression 
hardware and to a determination that the data 

to be transferred is compressed for setting the 
characteristics of the utilization means and de- 
compression hardware to match characteristics 35 
of the compressed data. 

13. A system as claimed in any one of claims 8 to 

12 including means (304, 406) for determining 
whether data to be transferred is compressed 40 
or uncompressed and an application program 
(206) for issuing requests for data transfer ei- 
ther to said utilization means or to the applica- * 
tion program itself, in which the system further 
includes means (310) responsive to requests 45 
for data transfer to the application program 
itself and to a determination (304) that the data 

is compressed to control the file I/O handler 
(212) to decompress (222) that data. 
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